\documentclass[a4paper,10pt]{article}

\usepackage[utf8x]{inputenc}
\usepackage[french]{babel}
\usepackage{hyperref}
\usepackage[margin=2cm]{geometry}
\usepackage{tikz}
\usetikzlibrary{shadows,arrows,shapes}
\usepackage{pgf-umlcd}
\usepackage{minted}
\usepackage{cite}


% Title Page
\title{ICAFE: projet de bibliothèque Python pour le développement de méthodes de résolution avancées de problèmes élément-fini}
\author{Ludovic Barrière}


\begin{document}
\maketitle

\tableofcontents

\section{Contexte et identification du besoin}

\subsection{Introduction}

Le développement de méthodes de résolution nécessite de disposer d'un code
pour leur implémentation et l'étude de leurs performances numériques. Pour développer efficacement de nouvelles méthodes ou stratégies
de résolution, il faut pouvoir réutiliser tout ou partie des développements existants ou greffer des fonctionnalités à différents endroits dans
l'architecture d'un code éléments finis. Cela peut se situer au niveau d'un seul ou d'un ensemble d'éléments, comme au niveau d'un domaine
géométrique, ou encore celui d'une formulation ou d'un solveur. 

La parallélisation est également importante. On peut considérer deux types de parallélisme selon l'architecture, sachant que les
deux types peuvent être associés dans une même application. Il y a donc le parallélisme à mémoire distribuée et le parallélisme à mémoire partagée. Le
premier permet de lancer des calculs sur des clusters de calcul à architecture distribuée, mais est plus intrusif que le second en termes de
programmation. C'est pourquoi il est nécessaire de le prendre en compte dès la conception du code.

Enfin, il est important pour un laboratoire de recherche de capitaliser les développements réalisés au fil des années, des contrats et des thèses.
Cela donne une cohérence supplémentaire et accélère les avancées de la recherche. Néanmoins, il faut garder à l'esprit que toutes les
méthodes ne peuvent être implémentées dans un même code. \`A moins d'avoir identifié clairement tout un pan de recherche relatif à quelques méthodes,
qu'il sera possible d'explorer avec un seul et même outil, l'investissement d'un laboratoire doit être mesuré. Les éditeurs de logiciels commerciaux
sont d'ailleurs confrontés aux limites des choix initiaux en termes de langage ou de conception, et le changement représente alors un coût (en temps
et en argent) qui peut freiner les velléités en termes d'innovation.

Nous avons donc choisis de capitaliser les développements sous la forme d'une bibliothèque écrite en langage Python \cite{python} de
manière orientée objet, que nous avons nommée ICAFE (Institut Clément Ader Finite Elements). Le format d'une bibliothèque se prête en effet à la
réutilisation de tout ou partie des développements. La cohérence des composantes de cette bibliothèque permet d'associer les fonctionnalités désirées
dans un programme nouveau. Enfin, ce format est favorable au développement incrémental, par couches successives. Le paradigme objet augmente par
ailleurs la modularité et la rapidité de développement de greffons. Pour finir, le langage Python, de plus en plus utilisé pour la recherche
scientifique, tous domaines confondus, est privilégié pour plusieurs raisons. La première tient de la simplicité et de la rapidité de développement
permises par ce langage interprété grâce à un typage dynamique et une syntaxe épurée. La lisibilité du code est également renforcée par la sensibilité
aux tabulations. La question de la performance est souvent un argument formulée à l'encontre de ce langage. Bien que pour certaines applications
critiques il soit préférable de travailler avec des langages plus proches de la machine (C/C++/Fortran), il est tout à fait possible d'utiliser Python
pour du calcul haute performance \cite{Pycuda2009}. D'autant plus que Python peut faire appel à des fonctions en C/C++ ou Fortran de manière efficace
et relativement simple pour le programmeur \cite{Behnel2011}. Certaines bibliothèques Python d'algèbre linéaire sont d'ailleurs implémentées en C
(basées sur LAPACK, ATLAS, PETsc). Dans le but de développer de méthodes avancées, de démontrer des concepts, de tester et comparer des algorithmes,
Python apparaît donc comme un bon compromis en termes d'investissement en programmation de la part des chercheurs et de performance des codes de
calcul scientifique. 
 
Premièrement, un bref état de l'art des concepts proposés pour la programmation orientée objet de la méthode des éléments finis en mécanique des
structures, ainsi que pour les méthodes de décomposition de domaine, est présenté dans ce document. Dans un second temps, la conception retenue et
l'état actuel de la bibliothèque ICAFE, sont exposés. Cet outil de recherche n'est pas achevé au terme de cette thèse, aussi les outils de
collaboration et de gestion de version sont introduits dans un troisième temps.

\subsection{Littérature en POO pour les éléments-finis}

La programmation orientée objet offre plus de modularité, de ré-utilisabilité et de flexibilité qu'une programmation procédurale. De plus en plus
d'outils de simulation numérique, académiques ou industriels, reposent sur le paradigme objet, notamment en langage C++. Les concepts de base de la
programmation orientée objet peuvent se résumer à l'encapsulation, l'héritage et le polymorphisme \cite{Meyer1988}. Cependant de nombreux patrons de
conception peuvent être constitués à partir de ces simples concepts \cite{Wolfgang1994,Gamma1999}. Ces patrons de conception (ou \emph{Design
Patterns}) répondent à des problématiques récurrentes en conception logiciel. \cite{Heng2009} ont proposé des \emph{Design Patterns} pour la
conception d'un code éléments-finis. Nous proposons une brève revue des conceptions choisies dans la littérature.\\

Dans le cadre de la simulation numérique par la méthode des éléments-finis, des recherches ont donc été menées sur la façon de concevoir un code
modulaire qui réponde aux forts besoins d'évolutivité de la méthode (formulation de nouveaux éléments, nouvelles équations constitutives, nouvelles
méthodes de résolution, ...). Des classes de base qui décrivent les entités d'un modèle éléments finis (degré de liberté, nœud, élément, maillage) ont
été introduites par \cite{Miller1988}. La formulation du problème en est indépendante et peut former une autre classe \cite{Peskin1988}. Dans un cadre
non-linéaire matériau, le point de Gauss et le matériau peuvent avantageusement faire partie des objets de base \cite{Menetrey1993}.
\cite{Dubois1998} se sont concentrés sur la conception des objets supervisant le modèle éléments finis pour l'analyse non-linéaire. Une classe
\texttt{Problem} contient le modèle, une méthode de continuation et une méthode de résolution. La méthode de résolution peut faire appel à des
classes dérivées d'une classe abstraite (i.e. dont certaines méthodes ne sont pas implémentées) \texttt{NonLinearSolver} ou d'une classe abstraite
\texttt{LinearSolver} selon les caractéristiques du problème. Il est alors aisé d'ajouter des classes \texttt{NewtonRaphson},
\texttt{ModifiedNewtonRaphson} ou \texttt{BFGS} qui implémentent la classe \texttt{NonLinearSolver}. De la même façon l'ajout de solveurs linéaires
est simplifié par les classes abstraites qui définissent les entrées/sorties et les méthodes des solveurs linéaires et non-linéaires. 

La problématique d'amélioration de la performance numérique a été abordée par \cite{Pantale2005} à travers la parallélisation de l'assemblage dans un
code orienté objet, ayant sensiblement la même structure de classe que celle présentée plus tôt. L'encapsulation des données dans les classes de
manière hiérarchisée (du degré de liberté au maillage complet) donne en effet une indépendance entre les éléments qui permet de
paralléliser très directement le calcul des opérateurs élémentaires, via un protocole de \emph{multi-threading} à mémoire partagée comme OpenMP
\cite{OpenMP}. %\cite{Modak2002}
La parallélisation de la résolution peut se faire également par l'implémentation de méthodes de décomposition de domaine. Dans une bibliothèque
existante (logiciel ZéBuLoN \cite{Zebulon}), \cite{Gosselet2003} a ainsi proposé l'ajout d'une classe \texttt{PARALLEL\_FORMULATION}. Cette classe
dérive d'une classe \texttt{IT\_S\_OPERATOR} qui réalise les opérations classiques d'une boucle d'un solveur itératif \texttt{ITER\_SOLVER} (produit
matrice/vecteur, produit scalaire, préconditionnement, projection). La formulation parallèle repose sur une description des sous-domaines et de leurs
interfaces par des objets spécifiques. Le traitement de chaque sous-domaine est affecté à un processeur, ce qui assure la localisation des données.
Les degrés de liberté d'interface sont également stockés au niveau local dans une classe \texttt{BOUNDARY}. Une représentation des interfaces locales
entre les domaines deux à deux (par connectivité) est privilégiée pour la communication entre les sous-domaines voisins. Les opérateurs d'interface
(complément de Schur, préconditionneur, scaling, second membre condensé) sont aussi représentés par une classe qui dérive de la classe
\texttt{B\_OPERATOR}. Grâce à une instance d'une classe \texttt{EXCHANGER} qui propose des méthodes de communication (envoie et réception de message),
la résolution itérative du problème d'interface (par un algorithme de type Krylov) peut être effectuée en parallèle. Les objets ``compléments de
Schur'' disposent ensuite d'une méthode pour la localisation de la solution à l'intérieur des sous-domaines. Cette implémentation orientée objet de la
méthode de décomposition de domaine autorise la définition de plusieurs types d'interface (primale, duale ou mixte) et l'ajout de différents
opérateurs comme les préconditionneurs, les scalings, les problèmes grossiers. 

En ce qui concerne la réduction de modèle, \cite{Aquino2007} a proposé un implémentation orientée objet de la POD. Une classe \texttt{POD} gère le
sous-espace (snapshots, matrice de corrélation, base réduite POD). Le modèle réduit est également représenté par une classe \texttt{ReducedModel} qui
réalise l'intégration des opérateurs élémentaires dans le sous-espace réduit plutôt que de projeter le système assemblé. La classe
\texttt{ReducedModel} hérite, comme la classe \texttt{FullFEModel} du modèle complet, d'une classe \texttt{BasePDE}, ce qui rend possible le passage
d'un modèle complet à un modèle réduit, et permet d'ajouter d'autres types de modèles réduits.

Une implémentation orientée objet de la méthode XFEM est proposée dans \cite{Bordas2007}. D'une part, les classes de base d'un code éléments finis
sont modifiées, ceci notamment pour intégrer l'ajout de degrés de liberté à certains nœuds. Le calcul de la matrice d'interpolation et de la
matrice des dérivées des fonctions d'interpolation des éléments est adapté pour prendre en compte l'enrichissement. Au niveau du problème global,
l'enrichissement mène parfois à des dépendances linéaires dans la matrice de raideur qui sont supprimées par une méthode spécifique. D'autre part, des
classes supplémentaires sont créées pour gérer les fonctions d'enrichissement (\texttt{EnrichmentFunction}) et la description des entités
physiques et géométriques nécessitant un enrichissement tels que les fissures, les trous ou les interfaces entre matériaux. Une classe particulière
pour les règles d'intégration numérique est proposée (classe \texttt{IntegrationRule}) ce qui permet de dériver plusieurs méthodes de la littérature
\cite{Belytschko2009}.


\section{Cahier des charges}

L'étude bibliographique des stratégies de résolution avancées en \autoref{chap:bib2} a permis de mettre en lumière quelques approches actuelles mais
il n'est bien sur pas envisageable de construire un code de recherche qui les intègre toutes. Au regard des travaux de cette thèse, des
perspectives qui sont ouvertes, et des activités du laboratoire en termes de développement de méthodes numériques \cite{Passieux2013,Gogu2010}
certaines méthodes, et leur combinaison, sont privilégiées. Nous présentons ces méthodes et les contraintes associées en termes de fonctionnalités
d'un code de recherche:
\begin{itemize}
 \item \textbf{Décomposition de domaine}: différentes méthodes de décomposition de domaine sans recouvrement ont été présentées en
\autoref{chap:bib2}. Plusieurs types de raccords doivent pouvoir être définis afin d'étudier leur influence pour un problème donné, les
préconditionneurs et les problèmes grossiers les plus adaptés. Il peut être également intéressant de définir une décomposition de domaine imbriquée
(multi-niveaux) pour traiter efficacement des problèmes fortement multi-échelles. 

 \item \textbf{Réduction de modèle par projection}: ces méthodes nécessitent de pouvoir construire une base réduite et de réaliser une projection de
Galerkin du système d'équations. L'introduction de cette fonctionnalité, dans un solveur, ne présente pas de difficulté particulière. L'intégration
réduite des équations d'équilibre doit cependant être possible pour améliorer les performances de la réduction de modèle comme cela est envisagé pour
les stratégies PBAMR et PBAMR-DD (voir \autoref{subsec:apriorireduction} et \autoref{chap:PBAMR-DD}).

 \item \textbf{Méthodes X/GFEM}: l'enrichissement d'interpolation par les méthodes X/GFEM offre une grande flexibilité pour augmenter le degré
d'interpolation ou introduire une description implicite de la géométrie. Pour cela, il faut prévoir l'ajout de degrés de liberté aux nœuds et leur
association avec des fonctions d'enrichissement. Les fonctions d'enrichissement doivent pouvoir faire appel à une description implicite de
la géométrie (e.g. fonctions \emph{level set}). Cette fonctionnalité permettrait d'approfondir l'étude de l'approche par enrichissement en
post-flambement local présentée en \autoref{annexe-PB-GFEM}.

 \item \textbf{Méthodes multi-grilles}: dans ces méthodes, plusieurs discrétisations sont associées à la même zone géométrique, et
celles-ci ne sont pas toujours imbriquées et ne coïncident pas forcément entre elles sur leurs contours. Il est donc important de pouvoir associer
plusieurs maillages à une zone géométrique et de pouvoir construire les opérateurs de prolongation et de restriction qui permettent de transférer
l'interpolation d'un champ d'un maillage à un autre. Certaines méthodes multi-grilles (Arlequin \cite{Ben_dhia1998}) font évoluer un maillage raffiné
local par dessus un maillage grossier (suivi d'un phénomène local, propagation de fissure) \cite{Ben_dhia2010,Passieux2013}. 

\end{itemize}


\section{Conception}

  \subsection{Modélisation UML}

La bibliothèque ICAFE ne vient pas se greffer sur un outil existant, ce qui laisse plus de liberté mais oblige à traiter l'ensemble des composantes
d'un code éléments-finis. La \autoref{fig:icafe-general} montre l'organisation de la bibliothèque proposée sous la forme d'un diagramme UML
(www.uml.org). Elle s'articule autour de package (ensemble de classes) pour en faciliter la réutilisation par entité fonctionnelle. Chaque package est
représenté avec ses classes principales. 

\input{icafe-uml-global}


  \subsection{Détails sur les packages}

   \subsubsection{Les packages supports}

      \paragraph{stepManager.py: pilotage des conditions limites}


\input{icafe-stepmanager-uml}


      \paragraph{problem.py: gestion des simulations}

      \paragraph{userInterface.py: interfaces utilisateurs}

      \paragraph{parser.py: lecture/écriture des entrées/sorties}


    \subsubsection{Les packages dédiés au développement de méthodes avancées}
      
      \paragraph{mesh.py: discretisation}
      
      \paragraph{domain.py: description géométrique, découpage et raccords entre sous-domaines}

      \paragraph{solver.py: méthodes de résolution}


 

\subsection{Utilisation}

    \subsubsection{Idée générale}


    \subsubsection{Exemples d'utilisation}


    \subsubsection{Ajout de fonctionnalités}


\section{Organisation du Projet ICAFE}

  \subsection{Langage, bibliothèques et conventions}




  \subsection{Collaboration et gestion des versions}

Dans un premier temps, la collaboration peut prendre plusieurs formes, de manière souple, afin de privilégier une mise en route rapide. Neanmoins, à
terme, l'utilisation d'un dépôt muni d'un gestionnaire de version sera privilégiée.
 
  \subsubsection{Dépôt icafe et Mercurial}

Un dépôt a été créé (\url{https://code.google.com/p/icafe/}). Le principe est de partager les derniers avancements de chacun des collaborateurs. Pour
être collaborateur et utiliser le dépôt il faut posséder un compte gmail et faire une demande à l'\href{mailto:lubar154@gmail.com}{administrateur} ou
se référer à la section suivante \ref{subsec:coll2}.

L'utilisation du dépôt nécessite l'installation du gestionnaire de version \href{http://mercurial.selenic.com/wiki/Mercurial}{Mercurial} (libre et
gratuit). Une fois installé, il suffit au collaborateur de créer un clone du dépôt sur sa machine par la commande suivante:
\begin{verbatim}
 hg clone https://lubar154@code.google.com/p/icafe/ nom_dossier_local
\end{verbatim}

\subsubsection{Utilisation simplifiée}

Un contributeur peut réaliser des modifications, ajouts (\texttt{hg add mon\_fichier})  ou suppressions (\texttt{hg remove mon\_fichier}) de
fichiers en local et les enregistrer à un instant donné sous-forme de révisions (``commit'') numérotées (de manière unique) et commentées (``commit
message''): 
\begin{verbatim} hg commit -m "mon message"\end{verbatim}
 En tapant la commande suivante, l'utilisateur peut visualiser la différence
entre l'état courrant et l'état de la dernière révision enregistrée:
\begin{verbatim} hg status \end{verbatim}
Les fichiers impactés seront identifiés par:
\begin{itemize}
 \item M: modifiés
 \item A: ajoutés
 \item R: supprimés
 \item !: manquants
 \item ?: inconnus
\end{itemize}

Une fois les changements effectués et enregistrés sous forme de révisions en local, ces dernières peuvent être partagés entre les collaborateurs.
Le partage consiste à envoyer les révisions effecutées en local sur le dépôt. Pour vérifier que les révisions ont bien été prises en compte et
comparer l'état du dépôt et de son clone, il suffit de taper la commande: \texttt{hg outgoing https://lubar154@code.google.com/p/icafe/} qui renvoie
la liste des révisions non présentes sur le dépôt. Il reste ensuite à ``pousser'' ces révisions via la commande suivante:

\begin{verbatim}
 hg push https://lubar154@code.google.com/p/icafe/
\end{verbatim}

A l'inverse, pour récupérer des révisions depuis le dépôt, qui aurait été réalisé par d'autres collaborateurs, il faut les ``tirer'':

\begin{verbatim}
 hg pull https://lubar154@code.google.com/p/icafe/
\end{verbatim}

De la même façon il est possible de vérifier au préalable les révisions manquantes dans le répertoire local (\texttt{hg incoming
https://lubar154@code.google.com/p/icafe/}). Le fait de tirer les révisions d'un dépôt ne modifie pas automatiquement l'état courant du répertoire
local. Pour cela il faut faire une mise à jour:
\begin{verbatim}
 hg update
\end{verbatim}
Cette commande permet aussi de travailler à partir de n'importe quelle révision en indiquant son ``hash'' (identifiant unique délivré
automatiquement au moment d'un ``commit''), son ``local revision number'' (identifiant local non immuable attribué en fonction de la
chronologie des révisions) ou son ``tag'' (non donné par l'utilisateur pour faire référence à une révision de manière simple et unique). La commande
\texttt{hg tag mon\_tag} affecte un tag à une révision et crée en même temps une nouvelle révision qui prend le tag comme une
modification. On peut alors passer d'une révision à l'autre comme suit, sachant que la dernière version en date porte toujours le tag \textit{tip}:
\begin{verbatim}
 hg update mon_tag
\end{verbatim}

\subsubsection{Utilisation avancée: gestion des branches et des conflits}



\subsubsection{Pour aller plus loin}
Une documentation plus complète sur Mercurial se trouve ici: \href{http://mercurial.selenic.com/wiki/Mercurial}{Documentation Mercurial} et un
tutoriel bien fait est présenté ici: \href{http://prezi.com/aqvjis65k6it/mercurial-basics/}{Tutoriel Mercurial}

  \subsubsection{Autres moyens de collaboration \label{subsec:coll2}}
  
Afin de centraliser les travaux des divers contributeurs, ces derniers peuvent envoyer par mail ou par un lien vers un google document à télécharger,
l'ensemble de leurs fichiers dans un dossier compressé. Le destinataire se charge ensuite de la mise à jour du dépôt principal. Si des contributeurs
veulent modifier ou utiliser les fichiers du dépôt, il leur suffit de les télécharger directement sur le dépôt, à l'adresse suivante:
\url{https://code.google.com/p/icafe/source/browse/}.
  
  


  \subsection{Planification}



\bibliographystyle{apalike-fr}
\bibliography{./Biblio}

\end{document}          
